In a distributed computer system, a multitude of applications cooperate with each other to provide a set of services to clients. To cooperate with each other, applications may need information about each other. Such information may include configuration data, such as port configuration data, and system load data. For example, a business application provides confidential pricing information to users. Before a user is permitted to receive the information, the user logs on to the business application, supplying to the application a password and a user name. To authenticate the user, the business application transmits to an authentication server an authentication request that includes the password and username. The authentication server uses the password and user name to determine whether the user is authorized to receive the pricing information. To cause an authentication server to verify whether a user is authorized, the business application needs certain information about other services. In particular, the business application needs information about who provides authentication services, which port to transmit an authentication request to, and whether the authentication service is currently accepting requests.
One technique for providing such information uses a “name service”. A name service is a computer component (e.g. a set of processes) dedicated, at least in part, to registering information received from clients and providing information to clients that request the information. Clients who register information with a name service or who request registered information are referred to as name service clients. A name service allows a name service client to make information available to other name service clients. To make information available to name service clients, a name service client transmits a publication request to a name service. A publication request is a request to make information available to a set of name service clients that request the information. A name service client who issues a publication request is referred to as a publishing client. Typically, the publication request includes a key and data associated with the key. The data associated with the key is referred to as published data because once a name service receives the published data and the associated key, the name service returns the data to any name service client requesting data associated with the key. Making data available in this manner is referred to as publishing the data.
For example, upon initialization, an authentication server transmits the string “PORT=1560” along with a key “AUTH-SERVER-A” to associate with the string. The business application, needing to know to what port to submit an authentication request, queries a name service. Specifically, the business application requests published data associated with the key “AUTH-SERVER-A”. In response, the name service returns the published data “PORT=1560”.
Typically, when a name service receives a publication request, it creates a name entry which associates the specified key with the specified published data. Over a period of time, a name service receives numerous publication requests, and creates name entries that associate the received published data with their corresponding keys. Overtime, the number of name entries can become unwieldy, many of them being stale, that is, no longer needed or valid (“stale”).
One technique for preventing the number of name entries from becoming unwieldy and to eliminate stale entries is referred to as the cooperative technique. Under the cooperative technique, the publishing client responsible for creating entries is responsible for deleting them, by, for example, requesting that the name service delete them.
Unfortunately, the cooperative approach is subject to certain types of errors. First, a computer malfunction may prevent the publishing client that created a name entry from deleting the name entry. Second, the publishing client may not delete an entry it creates simply because it is not configured to do so. Finally, two or more publishing clients may use the same key. Thus, when a first publishing client issues a publication request that includes the key “SAME KEY”, the key is associated with the published data specified by the request. When a second publishing client issues a second publication request that includes “SAME KEY”, the name service may overwrite the previous entry, and associate “SAME KEY” with the published data specified in the second request.
Because the name service depends on clients to delete a name entry they cause to be created, and those clients may not request the deletion of the entry, the number of name entries may become unwieldy if the name service relies solely upon the cooperation of the publishing entity. Thus, name services that use the cooperative technique also have a mechanism for removing entries when they are so “old”. Because it is possible that even old entries may not be stale, the name service applies age criteria that removes entries that are so old that their age leaves little risk that they are not stale. Unfortunately, under such age criteria, many stale entries persist, wastefully occupying memory with data that is not used.
Based on the foregoing, it is desirable to provide a method of deleting information in a name service soon after it is no longer likely to be needed, and to prevent entities from inadvertently overwriting entries created by other entities.